Első normálforma
Az első normálforma (1NF) relációs tulajdonság egy relációs adatbázisban. Egy reláció akkor és csak akkor van első normálformában, ha minden attribútuma egyszerű, nem összetett adat.[1] Vagy informálisabban: egyetlen táblázat oszlopban sem lehetnek táblák értékként. Az adatbázis-normalizálás az adatbázis-reprezentáció folyamata a normálformákban fennálló kapcsolatok szempontjából, ahol az első normál minimális követelmény. Az SQL nem támogatja a táblázatértékű oszlopok létrehozását vagy használatát, ami azt jelenti, hogy a legtöbb relációs adatbázis szükségszerűen első normálformában lesz. Az első normálformát nem igénylő adatbázis-rendszereket gyakran NoSQL-rendszernek nevezik.
Áttekintés
[szerkesztés]Egy olyan hierarchikus adatbázisban, mint az IBM Information Management System, egy rekord tartalmazhat gyermekrekordkészleteket, amelyeket ismétlődő csoportoknak vagy táblázatértékű attribútumoknak neveznek. Ha egy ilyen adatmodell relációként van ábrázolva, akkor az ismétlődő csoport egy attribútum, ahol az érték maga reláció. Az első normálforma kiküszöböli a beágyazott kapcsolatokat azáltal, hogy különálló „felső szintű” kapcsolatokká alakítja őket, amelyek a szülő sorhoz idegen kulcsok, nem pedig közvetlen elhatárolás révén társulnak.
A normalizálás célja a rugalmasság, az adatok függetlenségének növelése és az adatok nyelvének egyszerűsítése. Ez megnyitja az ajtót a további normalizálódás előtt is, amely kiküszöböli a redundanciát és az anomáliákat.
A legtöbb relációs adatbázis-kezelő rendszer nem támogatja a beágyazott rekordokat, ezért a táblák alapértelmezés szerint az első normálformában vannak. Különösen az SQL-nek nincsenek lehetőségei beágyazott táblák létrehozására vagy kihasználására. Az első normálformára történő normalizálás tehát szükséges lépés lenne, amikor az adatokat hierarchikus adatbázisból relációs adatbázisba helyezzük át.
Indoklás
[szerkesztés]Az 1NF-re történő normalizálás indoklása:[2]
- Lehetővé teszi a relációs adatok bemutatását, tárolását és cseréjét szabályos kétdimenziós tömbök formájában. A beágyazott kapcsolatok támogatásához összetettebb adatstruktúrákra lenne szükség.
- Leegyszerűsíti az adat nyelvét, mivel minden adat csak a reláció neve, az attribútum neve és a kulcs alapján azonosítható. A beágyazott kapcsolatok támogatásához összetettebb nyelvre lenne szükség, támogatva a hierarchikus adatútvonalakat a beágyazott adatelemek kezeléséhez.
- A kapcsolatok reprezentálása idegen kulcsok segítségével rugalmasabb, ahol a hierarchikus modell csak egy-sok kapcsolatot képviselhet.
- Mivel az adatelemek megkeresése nincs közvetlenül összekapcsolva a szülő-gyermek hierarchiával, az adatbázis jobban ellenáll az időbeli strukturális változásoknak.
- Lehetővé teszi további normalizálási szinteket, amelyek kiküszöbölik az adatredundanciát és anomáliákat.
Hátrányok és kritika
[szerkesztés]- Bizonyos műveletek teljesítménye. Hierarchikus modellben a beágyazott rekordokat fizikailag a szülőrekord után tárolják, ami azt jelenti, hogy egy egész alfa visszakereshető egyetlen olvasási művelettel. 1NF formátumban rekordtípusonként összekapcsolási műveletet igényel, ami költséges lehet, különösen az összetett fák esetében. Emiatt a dokumentum-adatbázisok elkerülik az 1NF-et.
- Az objektumorientált nyelvek futásidejű állapotot mutatnak, vagy fák vagy objektumok grafikonjai, amelyeket mutató vagy hivatkozás köt össze. Ez nem illeszkedik tisztán az 1NF relációs adatbázishoz, ezt a problémát néha Object-Relational Impedance Mismatchnek hívják, és amelyet az ORM könyvtárak megpróbálnak áthidalni.
- Az 1NF-et úgy értelmezték, hogy az nem engedélyezi az összetett adattípusokat. Ez azonban értelmezhető, és a CJDate azzal érvelt, hogy az értékek önkényesen összetett objektumok lehetnek.
Története
[szerkesztés]Az első normálformát E. F. Codd vezette be „A Relational Model of Data for Large Shared Data Banks” című könyvében, bár kezdetben csak „normálformának” hívták. Később átnevezték „első normálformára”, amikor további normálformákat vezettek be a relációs modell további normalizálása című kiadványban. [3]
Példák
[szerkesztés]A következő példák először azt szemléltetik, hogy az adatbázis-tervezés miként sértheti az első normálformát, és ezt követik a megfelelő példák.
Az 1NF-et sértő tervek
[szerkesztés]Az ügyfelek hitelkártya-tranzakcióit bemutató táblázat nem felel meg az első normálformának:
| Vevő | Ügyfél ID | Tranzakciók | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Ábrahám | 1 |
| ||||||||||||
| Isaac | 2 |
| ||||||||||||
| Jakab | 3 |
|
Minden ügyfélnek megfelel egy tranzakciók „ismétlődő csoportja”. Egy ilyen terv megjeleníthető hierarchikus adatbázisban, de nem SQL-adatbázisban, mivel az SQL nem támogatja a beágyazott táblákat.
Az ügyfelek tranzakcióival kapcsolatos bármely lekérdezés automatizált kiértékelése nagyjából két szakaszból áll:
- Egy vagy több ügyfélcsoport tranzakcióinak kicsomagolása, lehetővé téve a csoport egyes tranzakcióinak vizsgálatát, és
- Lekérdezés eredményének levezetése az első szakasz eredményei alapján
Például annak érdekében, hogy megtudja, a pénzösszeg összes ügylet történt 2003 októberében minden ügyfél számára, a rendszernek kellett volna tudnia, hogy először kicsomagolni a tranzakciók csoport minden ügyfelét, akkor összegezzük összegek valamennyi tranzakciót az így kapott tranzakció időpontja 2003 októberére esik.
Codd egyik fontos meglátása az volt, hogy a strukturális bonyolultság csökkenthető. A csökkentett szerkezeti bonyolultság a felhasználóknak, az alkalmazásoknak és a DBMS-eknek nagyobb hatalmat és rugalmasságot biztosít a lekérdezések megfogalmazásához és értékeléséhez. A fenti szerkezet normalizáltabb megfelelője így nézhet ki:
Az 1NF szabványnak megfelelő tervek
[szerkesztés]Ahhoz, hogy a modell az első normális formába kerüljön, elvégezhetjük a normalizálást. A normalizálás (az első normálformára) egy olyan folyamat, ahol a nem egyszerű tartományokkal rendelkező attribútumokhoz külön álló táblákat hozunk létre. A kivont relációkat idegen kulcsokkal módosítják, hivatkozva az azt tartalmazó reláció elsődleges kulcsára. A folyamat rekurzívan alkalmazható több szinten beágyazott nem egyszerű domainekre.[4]
Ebben a példában az ügyfél-ID az elsődleges kulcs a relációkat tartalmazva, ezért idegen kulcsként kerül hozzáadásra az új relációhoz:
| Vevő | Ügyfél ID |
|---|---|
| Ábrahám | 1 |
| Isaac | 2 |
| Jakab | 3 |
| Ügyfél ID | Tranzakció ID | Dátum | Összeg |
|---|---|---|---|
| 1 | 12890 | 2003. október 14 | − 87 |
| 1 | 12904 | 2003. október 15 | − 50 |
| 2 | 12898 | 2003. október 14 | − 21 |
| 3 | 12907 | 2003. október 15 | − 18 |
| 3 | 14920 | 2003. november 20 | − 70 |
| 3 | 15003 | 2003. november 27 | − 60 |
A módosított struktúrában az elsődleges kulcs az első relációban az {Ügyfél ID}, a második relációban az {Ügyfél ID, Tranzakció ID}.
Most minden sor egy egyedi hitelkártya-tranzakciót képvisel, és a DBMS megkaphatja az érdeklődésre adandó választ, egyszerűen megtalálja az októberi dátummal rendelkező összes sort, és összeadja az összegeket. Az adatszerkezet az összes értéket egyenlő alapon helyezi el, mindegyiket közvetlenül kitéve a DBMS-nek, így mindegyik közvetlenül részt vehet a lekérdezésekben; míg a korábbi helyzetben egyes értékek alacsonyabb szintű struktúrákba ágyazódtak, amelyeket külön kellett kezelni. Ennek megfelelően a normalizált kialakítás általános célú lekérdezések feldolgozására alkalmas, míg a normálatlan kialakításra nem.
Érdemes megjegyezni, hogy ez a kialakítás megfelel a második és a harmadik normálforma további követelményeinek.
Atomos állapot
[szerkesztés]Edgar F. Codd 1NF meghatározása hivatkozik az „atomitás” fogalmára. Codd kijelenti, hogy „azoknak a tartományoknak az értékeire, amelyeken az egyes relációk definiálódnak, atomnak kell lenniük a DBMS-hez képest”. [5] A Codd egy atomértéket úgy definiál, mint amelyet "a DBMS nem bonthat szét kisebb darabokra (kivéve bizonyos speciális funkciókat)" [6] vagyis egy oszlopot nem szabad olyan részekre bontani, amelyekben egynél több adattípus van, úgy hogy rész jelentése a DBMS számára ugyanazon oszlop egy másik részétől függ.
Hugh Darwen és Chris Date felvetette, hogy Codd „atomérték”-koncepciója kétértelmű, és hogy ez a kétértelműség széles körű zavart okozott abban, hogy miként kell érteni az 1NF-et. [7] [8] Különösen a „nem bontható érték” fogalma problematikus, mivel úgy tűnik, hogy ez azt sugallja, hogy kevés, ha van ilyen adattípus, atomi:
- Úgy tűnik, hogy egy karakterlánc nem atomi, mivel az RDBMS általában biztosítja a felhasználók számára, hogy részekre bontsák.
- Úgy tűnik, hogy egy fixpontos szám nem atom, mivel az RDBMS általában biztosítja a felhasználók számára, hogy egész és tört részekre bontsák.
- Úgy tűnik, hogy az ISBN nem atom, mivel tartalmazza a nyelvet és a kiadó azonosítóját.
Date szerint „az atomitás fogalmának nincs abszolút jelentése”: [9] [10] egy érték bizonyos szempontból atomnak tekinthető, de más célokra több alapvető elem együttesének tekinthető. Ha ezt a pozíciót elfogadjuk, akkor az 1NF nem határozható meg az atomitás alapján. Oszlopok minden elképzelhető adattípust (a karakterlánc típusú és numerikus típusok tömb típusú és táblatípusok) ezután elfogadható az egy 1NF; például kívánatosabb lehet az Ügyfél neve oszlopot két külön oszlopba választani, keresztnévként, vezetéknévként.
1NF táblák a kapcsolatok ábrázolása
[szerkesztés]Date definíciója szerint egy táblázat akkor és csak akkor van első normálformában, ha „valamilyen relációval izomorf”, ami konkrétan azt jelenti, hogy megfelel a következő öt feltételnek:[11]
- Nincsenek fentről lefelé rendezve a sorok.
- Nincsenek balról jobbra rendezve az oszlopok.
- Nincsenek ismétlődő sorok.
- Minden sor és oszlop metszéspontja pontosan egy értéket tartalmazhat.
- Minden oszlop szabályos (nem tartalmazhat rejtett összetevőket, például sorazonosítókat, objektumazonosítókat vagy rejtett időbélyegeket.)
Ezen feltételek bármelyikének megsértése azt jelentené, hogy a táblázat nem szigorúan relációs, és ezért nem első normálformában van.
Példák olyan táblákra, amelyek nem felelnek meg az első normálforma ezen meghatározásának:
- Táblázat, amely nem rendelkezik egyedi kulcskötelezettséggel. Egy ilyen táblázat képes lenne duplikált sorok befogadására, a 3. feltétel megsértésével.
- Olyan nézet, amelynek meghatározása előírja, hogy az eredményeket adott sorrendben adja vissza, így a sorrend a nézet belső és értelmes aspektusa. (Ilyen nézetek nem hozhatók létre az SQL: 2003 szabványnak megfelelő SQL használatával.) Ez sérti az 1. feltételt. A valódi kapcsolatok sorai nincsenek egymáshoz rendezve.
- Legalább egy nullázható attribútumot tartalmazó táblázat. Egy nullázható attribútum megsértené a 4. feltételt, amely előírja, hogy minden oszlopnak pontosan egy értéket kell tartalmaznia az oszlop tartományából. A 4. feltétel ezen aspektusa ellentmondásos. Fontos eltérést jelent Codd későbbi relációs modellel kapcsolatos munkái,[12] amelyek kifejezetten rendelkeztek a nullákról. Az első normálforma, amelyet Chris Date határoz meg, megengedi a relációértékű attribútumokat (táblák a táblákon belül). Date azzal érvel, hogy a relációértékű attribútumok, amelyek segítségével egy táblázat oszlopai tartalmazhatnak egy táblázatot, ritka esetekben hasznosak.[13]
Jegyzetek
[szerkesztés]- ↑ Codd, E. F. (1970). „A Relational Model of Data for Large Shared Data Banks”. Communications of the ACM. Classics. 13 (6): 377–87. p. 380-381
- ↑ Codd, E.F (1970). „A Relational Model of Data for Large Shared Data Banks”. Communications of the ACM. Classics. 13 (6): 377–87.
- ↑ Codd, E. F. (1971). Further Normalization of the Relational Model. Courant Computer Science Symposium 6 in Data Base Systems edited by Rustin, R.
- ↑ Codd, E.F (1970). "A Relational Model of Data for Large Shared Data Banks". Communications of the ACM. Classics. 13 (6): 377–87. p. 381
- ↑ Codd, E. F. The Relational Model for Database Management Version 2 (Addison-Wesley, 1990).
- ↑ Codd, E. F. The Relational Model for Database Management Version 2 (Addison-Wesley, 1990), p. 6.
- ↑ Darwen, Hugh. „Relation-Valued Attributes; or, Will the Real First Normal Form Please Stand Up?”, in C. J. Date and Hugh Darwen, Relational Database Writings 1989-1991 (Addison-Wesley, 1992).
- ↑ Date, C. J.. What First Normal Form Really Means. Apress, 108. o. (2007. november 8.). ISBN 978-1-4842-2029-0 „'[F]or many years,' writes Date, 'I was as confused as anyone else. What's worse, I did my best (worst?) to spread that confusion through my writings, seminars, and other presentations.'”
- ↑ Date, C. J.. What First Normal Form Really Means. Apress, 112. o. (2007. november 8.). ISBN 978-1-4842-2029-0
- ↑ Date, C. J.. SQL and Relational Theory: How to Write Accurate SQL Code. O'Reilly Media, 50–. o. (2015. november 6.). ISBN 978-1-4919-4115-7. Hozzáférés ideje: 2018. október 31.
- ↑ Date, C. J.. What First Normal Form Really Means. Apress, 127–128. o. (2007. november 8.). ISBN 978-1-4842-2029-0
- ↑ Date, C. J.. Appendix A.2, SQL and Relational Theory. O'Reilly (2009) „Codd first defined the relational model in 1969 and didn't introduce nulls until 1979”
- ↑ Date, C. J.. What First Normal Form Really Means. Apress, 121–126. o. (2007. november 8.). ISBN 978-1-4842-2029-0
Fordítás
[szerkesztés]Ez a szócikk részben vagy egészben a First normal form című angol Wikipédia-szócikk ezen változatának fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.